This is a lot of complexity for a nightly-only feature to allow safer autoreleases. I'm not sure why we need autoreleases to be safer. I'd say in rust people should only be using retain and release. Regardless, I'm not sure this would be worthwhile until the necessary features stabilize.

To elaborate on this:

I'm not sure why we need autoreleases to be safer. I'd say in rust people should only be using retain and release.

My understanding of autorelease is that it's predominantly used when returning an object so that it's the caller's responsibility to keep the object alive as long as it needs; you won't return them a +1 retain count object that they forget to release and now you've caused a memory leak in their code. I don't see how this problem applies to rust with its ownership system: I can return a smart pointer that will release the object when the caller is done with it and it drops. This seems like a strictly better and more idiomatic solution in rust, so I don't see why safe rust code should be using autorelease.

The primary motivator for this is to make a safe function using NSString's UTF8String that can return a &str without (external) cloning.

The documentation on UTF8String is a bit sparse and difficult to grok, but this is what I found with educated guesses and testing: NSString stores the equivalent of an NSData internally, sometimes with an UTF-8 encoding, sometimes in other encodings (UTF-16?).
When you send it UTF8String it checks the internal encoding:

• If the data is UTF-8 encoded, it returns a pointer into the internal NSData.
• If the data is in another encoding, it creates a new NSData and writes the UTF-8 representation of the string into it, autoreleases the NSData, and returns a pointer to that NSData.

What this means is that the lifetime of the returned pointer is either the same as the NSString OR the lifetime of the innermost @autoreleasepool. Since the pointer is not an object but rather an inner field in some object, we can't just retain the pointer. Hence we need the ability to describe the lifetime of the innermost @autoreleasepool, and that's exactly what this PR enables you to do.

For reference, objc-foundation's implementation is currently unsound on this point, it would break on the following:

extern crate objc;
extern crate objc_foundation;

use objc::rc::autoreleasepool;
use objc_foundation::{NSString, INSObject, INSString};

fn main() {
    let nsstring = NSString::from_str("String with non-ascii characters: 🔨");
    let s = autoreleasepool(|| {
        nsstring.as_str()
    });
    // `s` is invalid here
    println!("{}", s);
}

Running this with Guard Malloc (environment variable: DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib) unearths the segmentation fault consistently.

Also, fruity's implementation marks the function as unsafe for exactly this reason.

Secondary motivator is to be able to return autoreleased references for functions that inherently does that, like NSString's +stringWithUTF8String, NSMenuItem's +separatorItem, and many others without having to retain and release these objects unnecessarily!

A simpler (but also more restricting) version than all the thread local stuff in debug mode could also just be to use some other unsafe auto trait that AutoreleasePool isn't, like Sync or Send:

// Nightly w. feature
pub fn autoreleasepool<'p, T>(f: impl FnOnce(&'p AutoreleasePool) -> T + AutoreleaseSafe) { ... }
// Stable
pub fn autoreleasepool<'p, T>(f: impl FnOnce(&'p AutoreleasePool) -> T + Sync) { ... } // Or `Send`